![]() Time deterministic, distributed and synchronized execution system for control, test and measure appl
专利摘要:
Deterministic execution system in time, distributed and synchronized for control, test and measurement applications. Synchronized distributed time deterministic execution system for modules (m0, ..., mn) of control, test and measure that share at least one trigger signal and one clock signal, and that comprise a deterministic processor in time (100), which uses the clock signal and one or more of the trigger signals shared by all the modules (m0, ..., mn) to execute a program distributed in the modules (mo, ..., mn) with precise control of the instant of execution of each instruction and to synchronize the execution of all or part of the set of modules (m0, ..., mn). The deterministic processor in time (100) communicates with a signal bus (120) common to all the modules (m0, ..., mn), which comprises a control bus (120a) where the clock and trigger signals are shared. Optionally, the signal bus (120) includes a communication bus (120b) with which the deterministic processor is communicated in time (100) and also the modules (m0, ..., mn) with each other and, optionally, with an external processor or computer (130). (Machine-translation by Google Translate, not legally binding) 公开号:ES2552739A1 申请号:ES201531155 申请日:2015-08-03 公开日:2015-12-01 发明作者:Néstor Hugo OLIVERIO;Marc ALMENDROS PARRA 申请人:Signadyne Spain SL; IPC主号:
专利说明:
5 10 fifteen twenty 25 30 35 40 Four. Five fifty Deterministic execution system in time, distributed and synchronized for control, test and measurement applications. OBJECT OF THE INVENTION The present invention belongs to the technical field of electronics and, in particular, it is applied to the industrial area of programmable systems to execute control, test and / or measurement functions. More particularly, the present invention relates to a system for deterministic execution in time (ie, precisely controlling the execution time of each action, in a completely repeatable way and without any randomness), distributed and synchronized control applications, test or measurement, allowing multiple control, test and measurement instruments to perform a task by executing each of them part of the actions with total time synchronization. BACKGROUND OF THE INVENTION The requirements of the control, test and measurement systems have grown enormously in complexity in recent years, require increasing number of inputs / outputs, and greater capacity and speed of processing and synchronization. In the control, test and measurement systems it is very important to execute multiple simultaneous actions and / or with very precise times. Synchronized and real-time management of actions and the multiple inputs / outputs of a control, test or measurement system is a challenge that presents numerous inconveniences. And these problems grow significantly in complexity with the increase in the number of channels and the speed of the systems. To tackle this problem, current test and measurement systems use different architectures, as explained below. Some systems are implemented with a centralized main controller that monitors and controls all actions. This controller performs the calculations and triggers the measurement and control actions on the inputs and outputs of the peripherals, sensors and actuators. The main controller can be, among other examples, a computer, a microcontroller or an FPGA (in English, Field Programmable Gate Array), according to the requirements of robustness, real time and speed. Being a centralized controller, all tasks must be performed and synchronized from a single device, which significantly limits the speed and capabilities of the system. This limitation grows significantly with the number of inputs and outputs of the system and with the complexity of the tasks to be performed. All this results in performance (‘performance’) and limited time accuracy. In addition, scalability according to needs is also very restricted, so that, in general, centralized processing systems need to be custom designed for each application. The current trend is therefore to use modular architectures in control, test and measurement systems. In this way, maximum flexibility is achieved in terms of scalability, the possibility of using standard products from different suppliers, ease of repair and updating, etc. Some of these systems, the most modern, also incorporate the latest technologies in digital processing, such as FPGA and embedded processors, which allow a large processing capacity in each module. The great drawback of these systems is the ability to precisely synchronize all the 5 10 fifteen twenty 25 30 35 40 Four. Five fifty actions of the different modules and the calculations made in a distributed way to implement the complete test, measurement and control solution. In general to solve the synchronization, a truss of trigger signals ('trigger', in English) is used between the different modules that, according to the capabilities of each module, seeks to shoot sequentially, synchronously and accurately, the different actions of measurement, test and control. In many cases, the propagation time of these signals presents an important drawback that limits the accuracy of the system and also the complexity increases significantly with the number of modules involved. The implementation of these systems with trigger techniques (triggers) is usually very complex and requires a lot of development and start-up work. In addition, as the number of trigger signals is limited, the possibilities and flexibility are also limited. On some platforms, such as PXI Express, the system plans to include a special centralized module for generating trigger signals that can trigger actions on the other modules. This approach allows us to solve some triggers propagation problems and improve accuracy, but still has great limitations when synchronizing multiple modules with cross-trigger signal requirements. In addition, the centralized firing approach does not allow or is very poor to integrate the results of measurements and calculations distributed in several modules into the trigger actions. The objective technical problem that arises is thus to provide means for synchronized multi-module processing, in real time and deterministic in time of the plurality of inputs / outputs of any control, test and measurement system. DESCRIPTION OF THE INVENTION The present invention serves to solve the aforementioned problem, solving the problems presented by the solutions mentioned in the prior art, providing a deterministic distributed execution system in time for control, test and measurement applications, which allows to execute sequences by hardware. and programs with total temporal precision and synchronization between all the modules that make up the system. The present invention is based on a Time Determinist Processor (TDP: Time Deterministic Processor, in English), which can be part of the hardware of any equipment / control module, test and measurement. According to possible embodiments of the invention, the TDP processor may be implemented on a microprocessor, an FPGA device (in English. Field Programmable Gate Array) or an ASIC device (in English, Application Specific Intégrate Circuit: Circuit Integrated for Specific Applications), being FPGA or ASIC the most convenient platforms to give greater performance. The Time Determinist Processor (TDP) allows you to execute hardware instructions indicating with absolute precision the execution time of each instruction and all the control, test and measurement system modules, regardless of their function, for example, the generation modules of signal, digitization, communications, digital inputs and outputs, etc., all can incorporate adaptations of the same time deterministic processor, TDP. This TDP allows distributed processing and execution of synchronized global actions, such as synchronized conditional jumps, in all modules of the system according to the calculations, measurements or information of any of the modules. The propagation of decisions and the execution of global actions are carried out with complete synchronization in all modules and automatically and transparently for the user. One aspect of the invention relates to a distributed execution system comprising a set of two or more modules for executing control, test and measurement applications, sharing at least one trigger signal and a clock signal, where all the modules of 5 10 fifteen twenty 25 30 35 40 Four. Five fifty that set comprises a time-determined deterministic processor (TDP) that uses the common clock signal and at least one of the trigger signals shared by the modules to synchronize the execution of at least part of the module set (or the complete set). The invention can also be used with a single module, in which case the synchronization capabilities would not be used but all other functionalities and advantages of deterministic execution in time would be used. In the proposed distributed execution system, the precision in execution and synchronization times between the modules depends exclusively on the bias (skew, in English) and fluctuations (jitter, in English) of the clock signal common to all modules and, in particular , the time deterministic processor comprises calibration capabilities to cancel the clock bias between the modules. Some of the technical advantages presented by the invention over the prior art solutions are: - The present invention allows the user to program the hardware of the different modules by means of a very intuitive graphic environment, by text code or by generating order files (‘scripting’, in English). - Synchronized global actions, such as synchronized global jumps, are programmed extremely easily as if all modules were a single device and the execution was centralized. - At any time, the actions executed in any of the modules can be controlled with total temporal precision. - The programming of the modules can be carried out by means of a programming software that incorporates functionalities of timing verification ('timming', in English) and validation of synchronization in real time while programming, allowing to work with multiple modules simultaneously and very simple. - The invention has all the advantages of modular architectures and provides a fully scalable and distributed synchronized execution mechanism that provides absolute time accuracy and is very simple to use and start up regardless of the number of modules in the system. - The invention achieves a unique processing and synchronization speed, requiring a single Clock signal and a single multi-point trigger signal, both common to all modules, regardless of the number of modules in the system. This significantly simplifies the interconnection requirements between the modules with respect to the current systems that generally require numerous triggers, and even specific modules whose only function is to generate the triggers to synchronize the rest of the modules. - In the invention, the bias ('skew') of synchronization between the modules depends only on the bias in the clock signal ('clock skew') common to all modules, which is usually very low, and is independent of the bias in the trigger signals, which usually has much higher values than those of the clock and is very difficult to reduce in case of multi-point triggers. - The invention also incorporates the possibility of using multiple threads, deterministic 'threads' in time in the same module that, by means of a technique of interlaced instruction by instruction, guarantee a total accuracy of the times, something that in Conventional processors is impossible. - The system also provides tools to debug the software (‘debugging’, in English) that significantly simplify the implementation of multi-module control, test and measurement systems. For example, you have the possibility of entering global breakpoints (‘breakpoints’, in English) that stop 5 10 fifteen twenty 25 30 35 40 Four. Five fifty execution in a precise moment of time in all the modules of the system in a synchronized way. In the global system, modules with TDP and modules that do not include the technology described in the invention can coexist, because for this there are special instructions to generate and wait for trigger signals (triggers) and thus interact with these other modules, just like than with external events. BRIEF DESCRIPTION OF THE FIGURES A series of drawings that help to better understand the invention and that expressly relate to an embodiment of said invention which is presented as a non-limiting example thereof is described very briefly below. FIGURE 1.- Shows a block diagram of the architecture of the distributed processing system of control, test and measurement modules, according to a preferred embodiment of the invention. FIGURE 2.- Shows a block diagram of the architecture of a module of the distributed processing system with a Time Determinist Processor, according to a possible embodiment of the invention. FIGURE 3.- Shows a block diagram of the architecture of the System Time Determinist Processor, according to a possible embodiment of the invention. FIGURES 4.- Shows a schematic of the structure of the instructions used by the System Time Determinist Processor, according to a possible embodiment of the invention. FIGURES 5.- It shows a scheme of the process of programming, compilation and execution of the instructions in the hardware of the system modules, according to a possible embodiment of the invention. FIGURE 6A.- Shows a graphical interface of the synchronized multi-module programming software tool for the system, with multiple flowchart windows of different system modules, according to a possible embodiment of the invention. FIGURES 6B, 6C and 6D.- They show a flow chart window, respectively for each module, of the multi-module graphic programming tool of Figure 6A, according to a possible embodiment of the invention. PREFERRED EMBODIMENT OF THE INVENTION Next, possible embodiments of the proposed distributed execution system for control, test and measurement systems are described. Figure 1 shows a schematic diagram of the block architecture of the modular system for distributed execution in control, test and measurement applications. The system comprises multiple modules (M0, ..., Mn) which, in turn, comprise a plurality of inputs / outputs (IO0, ..., IO „) or l / O ports, of the English Input / Output. The modules (M0, ..., Mn) of the system perform control, test and measurement functions. Each module (M0, ..., Mn) is connected to a signal bus (120) common to all modules (M0, ..., Mn), which comprises a control bus (120a) through which all The modules (M0, ..., Mn) share one or more clock signals and one or more trigger signals or triggers. In addition, the signal bus (120) can include one or more communication buses (120b) through which each module (M0, ..., Mn) communicates with the rest and, optionally, with an external processor (130 ), which can 5 10 fifteen twenty 25 30 35 40 Four. Five fifty be a PC, an embedded controller, etc. Additionally, each module (M0, ..., Mn) can have one or more programming ports and programming debugging (110). Each and every one of the modules (M0, ..., Mn) has as its core a TDP processor or Time Determinist Processor (100). The TDP communicates with the signal bus (120) and the rest of the module also independent of the TDP. In Figure 2 the block diagram of the internal architecture of one of these modules (M0, ..., Mn) of the system of Figure 1 is shown more particularly. The module (Mi), i = 0, ... , n, is implemented in a device whose set of components or hardware (200) comprises in the core the Time Determinist Processor (100) which, in turn, may be implemented in a processing device (201): FPGA device, microprocessor, ASIC, etc. The device (201) communicates through the input / output ports (lOi) and the signal bus (120), with at least one clock signal and at least one common trip signal for all modules (M0, ..., Mn) of the system, requiring at least one trigger or trigger signal to be able to synchronize between modules. Figure 3 shows in a block diagram the architecture of the Time Determinist Processor (100) that is implemented with a core or core (300) common to all modules, which guarantees the correct functioning of the synchronization regardless of the type of instrument control, test and measurement, to which it is incorporated, and one or more specific blocks (P0, ..., Pn) for the execution of additional functions including the different specific functions that characterize each type of test and measurement module. This architecture allows you to easily incorporate new instructions to cover new requirements. The core (300) of the TDP processor (100) communicates with the rest of the components (301): hardware, data memory, input / output ports, etc., of the module and with the signal bus (120) common to All modules In addition, the core (300) of the Time Determinist Processor (100) reads, from a program memory (302), instruction words (303) used during the execution of the program in the hardware. The core (300) of the TDP (100) processes the instruction words (303) at the precise moment, executes the instructions corresponding to the core and also sends them to instruction executors (P0, ..., Pn), where interpret and execute additional instructions. Each executor -engine, in English- of instructions (P0, .... Pn) can execute one or more types of instructions (303) and there can be one or more instruction executors (P0, ..., Pn); their number and type of instructions they execute depends on each specific instrument. Figure 4 shows the structure of the instructions handled by the Time Determinist Processor (100). The instruction word of the TDP processor (100) has a special structure to include in at least one field (DW [1], DW [2]) the exact execution time of each instruction word, which can be absolute time, or relative to the previous instruction. It also contains a control field (DW [0j) that allows to enable the execution of one or more instructions that can be placed flexibly in the instruction word. The instruction word has a variable length according to the needs of the module in question, the larger the word, the more simultaneous instructions can be executed in each module, which is a very important advantage in control, test and measurement systems. The TDP processor (100) has special synchronization instructions and synchronized conditional jumps, which allow propagating a decision to all modules (M0, ..., Mn) of the system and for everyone to perform a conditional jump or other action according to this decision with total temporary synchronization. This is a unique feature of the TDP (100). To achieve this total synchronization, the TDP (100) requires a single clock signal and a single trigger or trip signal, both signals common to all modules (M0, ..., Mn). A trigger signal consists of a multi-point digital connection that connects all modules (M0, ..., Mn) to each other to form what is known as a "wired OR" or a "wired AND" according to the standard of logical interface -drivers, in English- to be used. In case the system counts 5 10 fifteen twenty 25 30 35 40 Four. Five fifty With more than one of these trigger signals, as is the case of the PXI Express platform that has eight trigger signals, the TDP (100) can optionally make use of the additional triggers to increase the synchronization and repetition speed of synchronized decisions and actions. In addition, the TDP processor (100) can integrate into the transfer of the communication buses (120b) decisions available in the modules (M0 ..... Mn). By For example, if a PXI or PXI Express control, test and measurement platform is used, the communications bus (120b) used by the time-based deterministic processor (100) is respectively a PCI-English bus, Peripheral Component Interconnect: Interconnection of Peripheral components- or a PCI Express bus. For example, a possible embodiment of the invention is implemented on the PXI or PXI Express platform which are a reference standard in control, test and measurement applications in most industries. A PXI Express chassis has a printed circuit board - backplane, in English - that distributes the following signals among all modules: power, a PCI Express bus, a 100MHz clock, CLK100, a 10MHz clock, CLK10, a signal of synchronization referred to the 100MHz clock and that provides a reference pulse at 10MHz, SYNC100, and 8 multi-point trigger signals, PXI Trigger Bus, which connect all modules in the form of “wired AND” with logic drivers of the type “ open collector ”, among others. The modules have an FPGA that communicates with a PC and with the specific hardware that makes up each specific type of control, test and measurement instrument. The PCI Express bus is used for communication between the PC and the FPGA; you can use some type of switch / device controller -switch / driver, in English-, or connect it directly to the FPGA. The FPGA controls PCI Express communication and other hardware components. Within the FPGA, the TDP (100) that works with the 100MHz clock, CLK100, is implemented to control with complete precision the instant of execution of each instruction and that uses the 8 PXI triggers bus and the SYNC100 reference signal, to achieve a perfect synchronized execution between all modules. The bias or skew in the synchronization between modules depends only on the bias of the 100MHz clock in the different slots of the chassis and is independent of the bias in the SYNC100 trigger and reference signals. The bias of the watch depends only on the chassis used and is guaranteed to be less than 250ps, although depending on the chassis it can be much lower and can also be significantly improved if an initial calibration is performed. The user can select which of the 8 available shots in the PXI Express want to allow to use the TDP (100) and the software manages the assigned resources. In the case of PXI, the CLK100 and SYNC100 signals are not available, so the implementation is implemented using the 10MHz clock, CLK10, and the 8 multi-point trigger signals. In PXI the communication bus used is PCI instead of PCI Express. Another possible embodiment of the invention is implemented on an LXI platform - English, LAN Extension for Instrumentation: Local Area Network Extension for Instrumentation -, where the clock signal and the bus trip signal (120a) communicate between the modules using the wired trip bus -Wired Trigger Bus, in English- provided in the LXI specification and where the communication bus (120b) consists of a LAN connection - from the English Local Area NetWork: Local Area Network-, Another possible embodiment of the invention is implemented on the microTCA platform -of the English Advanced Telecommunications Architecture: advanced telecommunications computing micro architecture- or some of its variants, such as microTCA.4, where the clock signal is communicated between the modules using some of the various clock ports referred to in the standard, CLK1, CLK2, CLK3, TCLKC or TCLKD, and the trip signals can communicate through ports 17 to 20. Where the communication bus (120b) can be selected from Ethernet, PCI Express or SRIO - from English, Serial Rapid Input Output: Inputs in Fast Serial Outputs, depending on the specific implementation of the system 5 10 fifteen twenty 25 30 35 40 Four. Five fifty Another possible embodiment of the invention is implemented on the AXIe-English platform, AdvancedTCA Extensions for Instrumentaron: Extension of AdvancedTCA for Instrumentation - where, similar to PXI Express, the CLK100 and SYNC backplane signals are used, and one or more of the 12 available MLVDS trigger signals and where the communication bus (120b) can be selected from a LAN connection or PCI Express The decision on which the global action or conditional jump is executed and the synchronization may depend on one or more modules (M0, ..., Mn) of the system. To force the synchronization of the modules (M0, ..., Mn), that is, to include an unconditional synchronization point, the same mechanism is used as in synchronized conditional jumps considering that the jump condition is always false. In addition, the TDP (100) has special synchronized execution instructions, such as the “Start” node, which allows the execution of all modules (M0, ..., Mn) to be started simultaneously. Synchronized actions, synchronized jumps and synchronization points can involve all modules (M0, ..., Mn) of the system or only a subset of them. The TDP (100) also has flow control instructions such as while, if, for etc, both local and multi-module synchronized. In addition, it has mathematical, logical, and data and variable access operations of the module itself or of the rest of the modules. And it has all the necessary instructions to control the specific capabilities of the module (Mi), i = 0, ...., n, on which it is implemented. The TDP (100) also has instructions for generating and waiting for triggers to interact with modules that do not incorporate a TDP (100) and with external events. There are two basic types of instructions that the TDP (100) can execute: - Instructions that are triggered and do not consume time from the TDP (100), that is to say, these instructions start execution and in the next clock cycle the TDP (100) can process a new instruction word and execute new instructions. These instructions may require several cycles for execution and are executed in parallel regardless of the operation of the TDP (100). - Instructions that consume a time of the TDP (100), so that until the execution of the TDP (100) cannot process the next instruction word and execute the following instructions; Typical examples are the wait, wait, or flow control instructions: while, for, if, etc. Time-consuming instructions are implemented in the core (300) of the TDP (100), while those that are not, can be implemented in both the core (300) and the instruction executors (P0, ..., Pn). In the case of the instructions that are triggered, it is possible that multiple executions can be started sequentially when the previous execution is still in progress and for them they are implemented using the filter-based architecture - pipeline, in English. The TDP (100) also has a deterministic system in time of threads or threads of execution, which allows to include in each module (Mi) more than one thread of execution that is executed in parallel with an interlaced technique instruction by instruction. This technique guarantees a deterministic distribution of the execution of the instructions in all threads, guaranteeing total accuracy of the times. The main execution thread is synchronized natively with the other modules and includes traffic lights and events that allow synchronizing the different threads of the same module with each other. It is also possible to select if you want to include any of the synchronized global instructions in one or more of the secondary threads. Figure 5 schematically shows the programming, execution and compilation process of the TDP instructions (100) of each module (M0, ..., Mn). The user programs the complete system or part of it, implementing a code for each of the modules (M0, 5 10 fifteen twenty 25 30 35 40 Four. Five fifty Mn) involved in the application of control, test and measurement. For the implementation of the code, local and global instructions are available to all modules (M0, Mn), already described above. For the first phase of the process, of entering the code (500), you can use tools for generating command files (501) or scripts, or text-based programming platforms (502) or graphics (503), Instructions Globals are executed in all modules of a group or in a subset and the TDP (100) guarantees their execution completely synchronized. Not all modules (M0, ..., Mn) of the system must work together, it is possible to have groups of modules that work together, which are programmed and work completely synchronized with each other regardless of the modules outside the group. The group is programmed with the ability to execute instructions on all of them synchronously as if they were a single hardware and can also include specific local instructions in each module. The source code written by the user can be graphic or text and is provided with graphical or script generation tools, as mentioned above, which allow you to easily add the synchronized multi-module instructions and the specific premises to each module. The programming tool performs all checks to maintain the consistency of the global and individual code and then compiles (510) the source code (511) of the group as a whole to obtain a compiled code (513), from which it is going to generate a specific execution code (CM0, .... CMn) for each module (M0 ...... Mn). In the compilation (510) converts the user's high-level instructions into the instructions that the TDP (100) can execute, whose compiler (512) manages the available trigger and communication resources to achieve synchronization automatically and transparently for the user and exchange of decisions between the modules (M0, ..., Mn). The compiler (512) verifies the correct syntax of all instructions and that there are resources needed at all times for its execution. In summary, the code entered (500) by the user is compile to generate the executable code (CM0, ..., CMn) specific to each module (M0 ..... Mn) and, during compilation, the compiler (512) of the TDP (100) generates the code necessary for the synchronization of each of the global instructions analyzing the synchronization in each section. The programming and compilation tool generally runs on a computer, but it could run on any other platform, and in addition the programming tool and the compilation tool could run on different platforms. The Executable codes (CM0 ..... CMn) generated for each module are downloaded to all modules of the group and then the code is executed by the TDP (100) synchronously in the hardware of each module of the system (530). The executable code download (CM0, ..., CMn) to each module (M0 ...... Mn) and the execution and debug control (520), using graphic tools (521), command (522) and / or library (523), can be done by the same communication bus (120b) that communicates all modules (M0, ..., Mn) with each other and with the PC or system controller if available, or through a specific programming port available in each module. For the programming of the hardware system (530) there is a graphic software, as shown in Figure 6A that allows you to easily program each module using one or more flowcharts, such as those shown in detail by way of example in Figure 6B-6D. The software allows you to select with which group of modules you want to work synchronously and create a project. Once the project is created, there is a flowchart window per module, an additional flowchart window for each thread, and additional windows for instruction editing and configuration, debugging, etc. For example, a properties window (640) is shown in Figure 6A, where some general parameters of the programming of the execution of the element selected at each moment and particular of the instructions of the element are configured, together with three diagram windows. flow: a flow chart window (600) for a first module, shown in detail 5 10 fifteen twenty 25 30 35 40 Four. Five fifty as an example in Figure 6B; another window (601) for a second module, shown in detail as an example in Figure 6C; and a third (602) for a third module, shown in detail as an example in Figure 6D. The software allows programming all modules simultaneously and automatically manages synchronized global elements. In addition, the software allows projects to be saved and then loaded with the same graphic software, with user libraries or with another code editing environment. User libraries allow you to load already created projects, modify them, compile them, load them into the hardware and control their execution completely. In this way, the execution of the hardware code can be integrated into any user application. From the user libraries you can start, pause, stop the execution, as well as exchange data and events between the PC and the modules. The user can have a collection or library of hardware programs that use the same or different modules and execute them at different times of the software execution. In addition, the software allows you to download the program to each module of the group, execute and debug the program, inspecting the variables, TDP status (100) and insert breakpoints or breakpoints, local and global. Local breakpoints stop only the execution of a module, while global ones stop all modules in the group. Global breakpoints are a very important tool in synchronized multi-module systems. These are introduced in one of the modules and replicated at the end of the same synchronized section in the rest of the modules of the group. The user can move the global breakpoints freely within each section, to adjust the exact stopping point of each module. The flow chart of each module is composed of instruction boxes and time arrows as shown in Figures 6A-6D. The arrows interconnect a source element with a target element in the flowchart and correspond to a specific execution time of the target element with respect to the source element. The time arrows indicate the exact time, indicated in nanoseconds (ns) in Figures 6B-6D, in which the execution of the next instruction with respect to the previous one will begin. Instruction boxes may contain actions, calculations, flow control instructions, data transfer, etc. The instructions can be local to the module or global multi-module synchronized. The synchronized elements (610, 611, 612, 613) are inserted in one of the modules and are automatically replicated in the other modules of the group. The software generates the necessary code to maintain synchronism and propagate decisions transparently to the user, guaranteeing the execution of all synchronized boxes at the same time. The boxes or local elements (620, 621, 622, 623, 624, 625, 626, 627, 628) of each module can maintain synchronism or not. There are cases in which local elements (620, 621, 622, 623, 624, 625, 626, 627, 628) of the module set (M0, ..., Mn), corresponding to local instruction words (303), when executed, they do not maintain synchronism between the modules, because the local instruction word (303) consumes a time not known by the compiler (512) before execution. In this case, synchronization between all modules is recovered in the global synchronized element following the local instruction word (303) that causes the synchronization. The local control boxes or structures that maintain synchronism are those that trigger actions and do not consume time, or those that consume time but this is known during compilation before execution. The local control boxes or structures that desynchronize are those whose execution time cannot be known at compile time, for example a While (621) command with a variable, or a Wait command of an external event. The software guarantees the synchronized execution of the boxes corresponding to synchronized elements (610, 611, 612, 613), which allows each section between synchronized global elements to be analyzed separately. If all local boxes in one tranche maintain the synchronism, the software can determine with total precision the execution time of each local instruction with respect to the synchronized start node of the section and thus automatically adjust the time of the last arrow before the end synchronization box of the section and achieve so that all the modules execute the synchronized element of end of the 5 section at the same time. If any of the local boxes desynchronizes, the software will not be able to accurately determine the time of the boxes from the point of desynchronization, but the synchronism between all modules in the synchronized box at the end of the section in question will be recovered: this is done with an additional procedure and indicated with the dotted line at the end of the section (630). Thus, for example, in Figure 6A, in the properties window (640), the 10 "Time" property of the selected local box (624) indicates that the box will run as At least 140ns after the immediately higher synchronization point, but it may take time to execute indefinitely depending on how many cycles the local While (621) instruction that is executed before the selected box (624) is repeated. 15 The software manages multi-module synchronization transparently to the user while programming, in this way the synchronized boxes are displayed aligned between all modules and the times are set in real time. This makes multi-module programming very simple, as if programming a single device. 20 In view of this description and figures, the person skilled in the art may understand that the invention has been described according to some preferred embodiments thereof, but that multiple variations can be introduced in said preferred embodiments or applied to different standard or customized platforms, without departing from the object of the invention as claimed.
权利要求:
Claims (18) [1] 5 10 fifteen twenty 25 30 35 40 Four. Five fifty 1. A synchronized distributed time deterministic execution system for control, test and measurement applications, comprising a set of at least one module (M0, ..., Mn) for executing control, test and measurement applications, characterized by that all modules (M0, ..., Mn) of the set share at least one trip signal and one clock signal, and comprise a time deterministic processor (100), where the time deterministic processor (100) uses the clock signal and one or more of the trigger signals shared by all modules (M0, ..., Mn) to execute a program distributed in the modules (M0, ..., Mn) controlling each instant of execution of each instruction of the program and, if the set comprises more than one module (M0, ..., Mn), to synchronize the execution in all or part of the set of modules (M0, ..., Mn). [2] 2. The distributed execution system according to claim 1, characterized in that the time deterministic processor (100) communicates with a signal bus (120) common to all modules (M0, ..., Mn), comprising a control bus (120a) that carries the clock signal and at least one trigger signal, shared by all modules (M0, ..., Mn). [3] 3. The distributed execution system according to claim 2, characterized in that the time deterministic processor (100) communicates with a communication bus (120b) incorporated in the signal bus (120) and by means of which modules (M0, ..., Mn) communicate with each other. [4] 4. The distributed execution system according to claim 3, characterized in that the modules (M0, ..., Mn) communicate with an external processor (130) via the communication bus (120b). [5] 5. The distributed execution system according to any of the preceding claims, characterized in that the time deterministic processor (100) has a core (300) common to all modules (M0, ..., Mn) and in the core (300) the time-determined deterministic processor (100) reads instructions (303) from a memory (302), executes at a certain instant of execution the instructions (303), which are selected from synchronized global instructions to all or part of the modules (M0, ..., Mn) and premises to each module, and pass the instructions (303) to at least one instruction executor (P0, ..., Pn) to execute additional functions, which are selected among functions common to all modules (M0, ..., Mn) and specific functions according to a control, test and measurement application of each module (M0, ..., Mn) .. [6] 6. The distributed execution system according to any of the preceding claims, characterized in that the time deterministic processor (100) executes an instruction word (303) comprising at least one field (DW [1], DW [2]) indicating an exact execution time of each instruction word (303). [7] 7. The distributed execution system according to any of the preceding claims, characterized in that the time deterministic processor (100) executes an instruction word (303) comprising a control field (DW [0]) that enables the execution of an instruction or multiple instructions simultaneously. [8] 8. The distributed execution system, according to any of the preceding claims, characterized in that the time deterministic processor (100) executes synchronized global instructions, synchronization and synchronized conditional jumps, propagating a decision to all or part of the modules (M0, ..., Mn) that, according to the decision, execute an action or a conditional jump with temporary synchronization. 5 10 fifteen twenty 25 30 35 40 Four. Five fifty [9] 9. The distributed execution system according to claim 8, characterized in that the decision propagated by the deterministic processor in time (100) among all the modules (M0, Mn) of the assembly and on which the conditional jump is executed o synchronized action depends on all, one or part of the module set (M0, ..., Mn). [10] 10. The distributed execution system, according to any of the preceding claims, characterized in that the time deterministic processor (100) executes generation instructions and expects at least one trigger signal to interact with external events and with other modules of the system that does not incorporate a deterministic processor in time (100). [11] 11. The distributed execution system, according to any of the preceding claims, characterized in that the time deterministic processor (100) uses execution threads to include in each module (M0, .... Mn) of the set more than an execution thread that runs in parallel with an interlaced technique instruction by instruction. [12] 12. The distributed execution system according to any one of the preceding claims, characterized in that the time deterministic processor (100) comprises a compiler (512) that converts a source code (511) with high-level instructions, introduced by a user for all modules (M0, ..., Mn) of the set as a single programmable device, in a compiled code (513) from which an executable code (CM0, .... CMn) specific for each module (M0, .... Mn) with instruction words (303), containing global synchronized and local instructions, executable by the time-determined determinist processor (100), where the compiled code (513) takes into account time Exact execution of each instruction word (303) for synchronization of all global instruction words (303) for all modules (M0, ..., Mn) of the set in the execution of the executable code (CM0, .. ., CMn) specific of each module (M0, ..., Mn). [13] 13. The distributed execution system, according to any of the preceding claims, characterized in that it comprises a graphical user interface through which the user enters high level instructions to program each module (M0, ..., Mn ) of the assembly by at least one flow chart comprising at least one synchronized element (610, 611, 612, 613) introduced by the user in one of the modules of the assembly and the at least one synchronized element (610, 611 , 612, 613) is automatically replicated in the rest of the modules of the set, to be executed as a global instruction word (303) at the same time by the time deterministic processor (100) of each module. [14] 14. The distributed execution system according to claim 13, characterized in that the graphical user interface additionally comprises arrows that interconnect a source element with a target element in the flowchart and that correspond to a particular execution moment of the target element with respect to the source element. [15] 15. The distributed execution system according to any of claims 13-14, characterized in that the graphic user interface additionally comprises local elements (620, 621, 622, 623, 624, 625, 626, 627, 628) to each module (M0, .... Mn) of the set corresponding to local instruction words (303), whose execution maintains synchronism with the global instruction words (303) only if the local instruction words (303) do not consume time or if they consume a time known to the compiler (512) before execution. [16] 16. The distributed execution system according to any of claims 13-15, characterized in that the user interface comprises global breakpoints a all or part of the modules (MO ..... Mn), which correspond to instruction words (303) special deterministic processor time (100) and stop the execution of the 5 time deterministic processor (100) at a specific point within the same synchronized section in all or part of the module set (M0, ..., Mn). [17] 17. The distributed execution system, according to any of the preceding claims, characterized in that it is implemented on a control, test and control platform. 10 measure that is selected between PXI and PXI Express. [18] 18. The distributed execution system, according to any of the preceding claims, characterized in that it is implemented on an LXI platform. The distributed execution system, according to any of the claims above, characterized in that it is implemented on a control, test and measurement platform that is selected from microTCA, microTCA.4, AXIe or an AdvancedTCA evolution. 20 20. The distributed execution system according to any of the claims above, characterized in that the time deterministic processor (100) is implemented in a processing device (201) that is selected between microprocessor device, FPGA or ASIC.
类似技术:
公开号 | 公开日 | 专利标题 US10019339B2|2018-07-10|Sequentially constructive model of computation ES2552739B1|2016-07-04|Deterministic Execution System in Time, Distributed and Synchronized for Control, Test and Measurement Applications Witsch et al.2011|PLC-statecharts: An approach to integrate UML-statecharts in open-loop control engineering–aspects on behavioral semantics and model-checking Berry2007|SCADE: Synchronous design and validation of embedded control software Pohlmann et al.2012|Generating functional mockup units from software specifications Duller et al.2005|Picoarray technology: The tool's story Navet et al.2016|Lean model-driven development through model-interpretation: the CPAL design flow Owda et al.2015|Trace-based simulation framework combining message-based and shared-memory interactions in a time-triggered platform Mistry et al.2011|FreeRTOS and multicore KR20180019109A|2018-02-23|A field programmable gate array including a plurality of functional blocks, and a control device Kirsch et al.2006|The evolution of real-time programming Lindgren et al.2014|Real-time execution of function blocks for internet of things using the rtfm-kernel Berger et al.2017|Code generation for STM32F4 boards with Modelica device drivers Wahler et al.2015|Real-time multi-core components for cyber-physical systems Derler et al.2016|Specification of precise timing in synchronous dataflow models Manione2019|A full model-based design environment for the development of cyber physical systems Pearce et al.2019|Synthesizing IEC 61499 Function Blocks to hardware Grassmann et al.2007|Mapping the physical layer of radio standards to multiprocessor architectures Pohl et al.2017|A Survey of Hardware Technologies for Mixed-Critical Integration Explored in the Project EMC2 Resmerita et al.2015|Addressing non-functional requirements for embedded applications with platform based aspect design Esquembri Martínez2017|Methodology for the integration of high-throughput data and image acquisition systems in EPICS Elhorst2014|Lowering C11 atomics for ARM in LLVM Fernandez-Rodriguez et al.2021|An open-source FPGA-based control and data acquisition hardware platform Zaera-Sanz2009|Evaluation and application of a fast module in a PLC based interlock and control system Seifert2022|Static Analysis Methodologies for WCET Calculating with Asynchronous IO
同族专利:
公开号 | 公开日 US20170039125A1|2017-02-09| ES2552739B1|2016-07-04| US11106565B2|2021-08-31| US20190266027A1|2019-08-29|
引用文献:
公开号 | 申请日 | 公开日 | 申请人 | 专利标题 US5287511A|1988-07-11|1994-02-15|Star Semiconductor Corporation|Architectures and methods for dividing processing tasks into tasks for a programmable real time signal processor and tasks for a decision making microprocessor interfacing therewith| DE69130630T2|1990-09-14|1999-09-09|Hitachi Ltd|Synchronous process and device for processors| US6151689A|1992-12-17|2000-11-21|Tandem Computers Incorporated|Detecting and isolating errors occurring in data communication in a multiple processor system| US5634004A|1994-05-16|1997-05-27|Network Programs, Inc.|Directly programmable distribution element| US6111888A|1997-05-27|2000-08-29|Micro Motion, Inc.|Deterministic serial bus communication system| JP3569275B2|2000-05-29|2004-09-22|株式会社アドバンテスト|Sampling digitizer, method therefor, and semiconductor integrated circuit test apparatus equipped with sampling digitizer| US6654818B1|2000-06-22|2003-11-25|International Business Machines Corporation|DMA access authorization for 64-bit I/O adapters on PCI bus| US8406715B2|2008-03-27|2013-03-26|Panasonic Automotive Systems of America, division of Panasonic Corporation of North America|Method and apparatus for dynamically adapting FM tuner sensitivity to a local environment for a single-tuner system| WO2012003997A1|2010-07-09|2012-01-12|Martin Vorbach|Data processing device and method| WO2012113007A1|2011-02-22|2012-08-30|Fts Computertechnik Gmbh|Predictable computing in virtualizated distributed computer systems based on partitioning of computation and communication resources| US8601486B2|2011-05-31|2013-12-03|International Business Machines Corporation|Deterministic parallelization through atomic task computation| US9443269B2|2012-02-16|2016-09-13|Novasparks, Inc.|FPGA matrix architecture| FR2993070B1|2012-07-09|2014-07-18|Commissariat Energie Atomique|METHOD OF EXECUTING, WITHIN A MULTITASTIC INBOARD SYSTEM, AN APPLICATION CADATED BY SEVERAL DIFFERENT TIME DOMAINS INCLUDING AN INTERRUPTION MANAGEMENT| US9137038B1|2012-08-30|2015-09-15|Rockwell Collins, Inc.|Integrated modular avionics system with distributed processing| ES2552739B1|2015-08-03|2016-07-04|Keysight Technologies Singapore Pte. Ltd.|Deterministic Execution System in Time, Distributed and Synchronized for Control, Test and Measurement Applications|ES2552739B1|2015-08-03|2016-07-04|Keysight Technologies SingaporePte. Ltd.|Deterministic Execution System in Time, Distributed and Synchronized for Control, Test and Measurement Applications| KR20180078864A|2016-12-30|2018-07-10|에스케이하이닉스 주식회사|Memory system and operation method of the same| US10840701B2|2018-06-01|2020-11-17|Keysight Technologies, Inc.|Instrumentation chassis with single output AC to DC power supply and DC to DC switching regulators|
法律状态:
2016-06-17| PC2A| Transfer of patent|Owner name: KEYSIGHT TECHNOLOGIES SINGAPORE (HOLDINGS) PTE. LT Effective date: 20160613 | 2016-07-04| FG2A| Definitive protection|Ref document number: 2552739 Country of ref document: ES Kind code of ref document: B1 Effective date: 20160704 | 2018-11-26| PC2A| Transfer of patent|Owner name: KEYSIGHT TECHNOLOGIES SINGAPORE (SALES) PTE. LTD. Effective date: 20181120 |
优先权:
[返回顶部]
申请号 | 申请日 | 专利标题 ES201531155A|ES2552739B1|2015-08-03|2015-08-03|Deterministic Execution System in Time, Distributed and Synchronized for Control, Test and Measurement Applications|ES201531155A| ES2552739B1|2015-08-03|2015-08-03|Deterministic Execution System in Time, Distributed and Synchronized for Control, Test and Measurement Applications| US15/198,147| US20170039125A1|2015-08-03|2016-06-30|System of implementing deterministic real-time, distributed and synchronized for control applications, test and measurement| US16/286,691| US11106565B2|2015-08-03|2019-02-27|System for time-deterministic, distributed and synchronized execution for control test and measurement applications| 相关专利
Sulfonates, polymers, resist compositions and patterning process
Washing machine
Washing machine
Device for fixture finishing and tension adjusting of membrane
Structure for Equipping Band in a Plane Cathode Ray Tube
Process for preparation of 7 alpha-carboxyl 9, 11-epoxy steroids and intermediates useful therein an
国家/地区
|